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Description 

The invention relates to a method for organizing and 
accessing product describing data, generated and used 
by an engineering process comprising multiple engi- 5 
nee ring subprocesses. 

The method of the invention relates in particular, but 
not exclusively, to intended use in an electronic engi- 
neering environment, such as computer aided design of 
an integrated circuit and its associated data files. The 
data may be either generated by the process, or used 
by the process, or both. This also applies on the sub- 
process level. Such an electronic or other engineering 
process requires a sequence of operation steps, of 
which a typical example could be a silicon compiler sys- 
tem such as described in United States Patent 
5,005,136. Successive steps may be: 

A. receiving a source text expressing an algorithm 
in an imperative concurrent computer language; 

B. converting this text to a structure tree as an ab- 
stract representation of the source text; 

C. converting^ to an abstract circuit 
representation featuring abstract channels; 

D. converting the abstract circuit to a concrete cir- 
cuit representation being constituted of gate level 
elements and wires; 

E. next, generating a so-called net-list, which spec- 
ifies all electronic elements and their interconnec- 
tions; 

F. from the net-list, generating a lay-out; 

G. from the lay-out so generated, executing a sim- 
ulated test operation. 

With increasing levels of complexity and sophistica- 
tion, the problems relating with managing such data, 
grow exponentially, inter alia by the design being a trial 
and error process. Systems for organizing and manag- 
ing the body of information with the intent of supporting 
the engineers involved may be called frameworks. Ac- 
cess must be easy and secure. This may be effected by 
placing the various data files or units under control of 
the system which itself possesses control information or 
design management data relating to the structure and 
usage of the data files or units. In a refined version, the 
system could use this control information to organize the 
data, to provide access to the data and to check request- 
ed operations on the data against integrity/security 
rules. The system also could provide support for certain 
project management aspects of the engineering proc- 
ess by providing an overview of the available data and 
their status. Important aspects to be dealt with may in- 
clude: 

what units of data belong together? 
what do the data represent? 
which version of the data is this? 
how was this data created? 
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where is this data used? 

The above recited problems have been solved in 
part by the following papers: 

D1 - "IDEAS"- An Integrated Design Automation 
System by Mehmood et al. f Proceedings of the 
1 987 IEEE Conference on Design: VLSI in Comput- 
ers and Processors, pages 407-41 2, and 
D2 - Mehmood et al. "A Design Data Management 
System for CAD", IEEE International Conference 
on Computer- Aided Design, Santa Clara, Novem- 
ber 1987, pages 220-223. Steps a-f and h of claim 
1 are known from the disclosure in these papers. 

Among other things, it is an object of the invention 
to provide a method for organizing and accessing prod- 
uct describing data pertaining to an engineering proc- 
ess, by devising a flexible and powerful set of concepts 
with which to describe the structure of various sets of 
engineering data upon their generation and use. Now, 
concepts used to model the structure of the engineering 
data include "versioning", "equivalence" and "alterna- 
tives", which in our method and system are basically 
handled using the derivation graph, to be discussed 
hereinafter. Versioning is a well-known concept in hard- 
ware and software for discerning between successive 
solutions. Equivalence puts various solutions on an 
equal footing. Alternatives are solutions basing on a par- 
ticular choice made. Now, the present invention is most 
suitable/useful under the following conditions: 

1 ) the data being managed is subject to numerous 
changes and/or updates such as is typical in trial 
and error engineering. The technique may be more 
suitable for work-in-progress data than for libraries, 
standards, archives or other bodies of consolidated 
data. 

2) the engineering process consists of a significant 
number of different steps which can each be redone 
independently of following steps: although previous 
steps must have rendered their results available, 
the process need not run to the end. A prime exam- 
ple of this is electrical engineering (VLSI, ASIC, dis- 
crete components). 

According to the invention, a method is provided as 
set out in claim 1 . 

So, the method boils down to mapping the subproc- 
esses one-to-one on the flow nodes, linking the flow 
nodes according to a data-to-data paternity pattern in a 
first graph, tethering to each flow node the data gener- 
ated by its execution, linking also the data nodes ac- 
cording to a data-to-data paternity pattern, and access- 
ing the data structure along lines of paternity linkage 
and/or tethering. In particular, the direction of accessing 
is now following the links in a downstream direction. This 
would answer questions like: where is this data used? 
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or which is the consequence of this particular phenom- 
enon encountered? Generally, this procedure would un- 
cover data that were generated by a particular execu- 
tion. 

5 

FURTHER ASPECTS TO THE INVENTION 

Advantageously, a second selection mechanism is 
provided which involves travelling uniformly along links 
of said first directed-acyclic-graph in a direction from the io 
destination nodes to the source nodes of the latter links. 
In particular, the direction of traversal is now following 
the links in an upstream direction. This would answer 
questions like: how is this data created? or what is the 
cause of this particular phenomenon encountered? is 
Generally, this procedure would uncover data that were 
used by a particular execution. Both upstream travelling 
and downstream travelling represent attractive access- 
ing strategies. 

Advantageously, each particular data link is coupled 20 
to exactly one flow link in that the product describing 
data represented by either end node of said data link 
originate from an execution of the processes corre- 
sponding to the respective end nodes of the thereto cou- 
pled flow link. 25 
Such secondary mapping forces to relevant linking in 
the data graph. It can also represent a means for addi- 
tionally checking upon each modification in the data- 
base. In particular cases, however, other realizations 
are feasible. 30 

Advantageously, the first directed-acyclic-graph is 
extended to an extended directed-acyclic-graph with in- 
formation about the way in which the product describing 
data, produced and used, respectively, by executions of 
the engineering sub-processes is physically partitioned 35 
into units and wherein the second directed-acyclic- 
graph is extended with information mapping said indi- 
vidual units of data residing within a storage system onto 
elements of the second directed-acyclic-graph. 
In this way, the system is able to control the flow of in- *o 
formation between programs at the level of individual 
units. Note that in most cases this additional level of de- 
tail can be kept transparent for the end-user. By itself, 
the grouping of data files to data sets, and, conversely, 
the distribution of data sets over data files is a conven- 45 
tionat database management concept, which in this 
case would facilitate the accessing. 

Advantageously, the flow nodes within the extended 
directed-acyclic-graph are provided with additional typ- 
ing information representing the type of engineering so 
subprocess of which they are an instance thereby allow- 
ing the usage of the flow nodes in the extended directed- 
acyclic-graph to be checked against said typing infor- 
mation. Such provision in the lowest level of the three 
levels (the engineering subprocess typing level) allows ss 
for additional integrity checking of the data structure. 

Advantageously, a further subset of the flow nodes 
of the first directed-acyclic-graph is provided with infor- 



mation pertaining to a physical location and method of 
invocation of executable programs corresponding to the 
respective elements of said further subset, thereby al- 
lowing the information in the first directed-acyclic-graph 
to be used to automate and/or support the execution of 
said executable programs. In this way, the program-re- 
lated information occurring in the flow nodes can be 
used to partially or fully automate the invocation of the 
programs in question. This can, for example, be used to 
implement additional functionality which is roughly com- 
parable to that of the MAKE facility as commonly used 
in UNIX software development environments. The latter 
have become in extensive use. 

Advantageously, an additional type of link is intro- 
duced interconnecting flow nodes in the first directed- 
acyclic-graph thereby representing non-mandatory use 
of product describing data by executions of the engi- 
neering subprocess corresponding to the destination 
node of said type of links. 

This feature is particular useful in editing tools. Alterna- 
tively certain types of iteration may benefit. In particular, 
an optional loop may be created in this way. In the par- 
ticular case of an editor, the output data thereof may be 
used as new input data, after original execution of the 
editor without provision of input data in first instance. 

Advantageously, the first directed-acyclic-graph 
forms a hierarchical model of the engineering process 
by linking nodes therein representing either individual 
engineering subprocesses or subgraphs of interlinked 
engineering subprocesses. Such useful feature of the 
present invention allows engineering subprocesses to 
be described in terms of lower level engineering sub- 
processes. Such a description may be called a nested 
flow description. Flow nesting can be used to hide lower 
level subprocesses from the user. For example, the se- 
quence of lower level subprocesses consisting of a pre- 
processor step, a tool execution and a post-processor 
step can be represented as a single higher level sub- 
process in which the pre- and post-processing steps are 
hidden. 

Another direct application of flow nesting involves 
assigning users, or groups of users, to one or more sub- 
processes in the hierarchy of subprocesses. This infor- 
mation can be used to restrict the accessibility and vis- 
ibility of product describing data generated by the exe- 
cution of any particular lower level engineering subproc- 
esses to those users who have been assigned to the 
engineering subprocess containing said particular lower 
level engineering subprocess. 

The latter application of flow nesting is a new ap- 
proach to providing functionality which is similar to that 
of the so-called workspace concept while avoiding some 
of the implementation and usage complexity associated 
with the workspace concept. 

As in the foregoing, executing any subprocess or 
lower level subprocess may again produce product de- 
scribing data which is mapped on a particular data node 
in the second directed-acyclic-graph. Depending on the 
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level of microscopism required, the level of subprocess- 
es is aggregated or kept disjunct, as the situation re- 
quires. 

Advantageously, such hierarchical description of 
the engineering process limits the accessibility and vis- 
ibility of product describing data generated by the exe- 
cution of flow nodes belonging to a particular level of the 
hierarchy to those users of the system with appropriate 
privileges for said particular level. 
Such accessibility, visibility, etcetera may represent sta- 
tus of the data, provide protected data access and in 
other aspects support or provide project management. 
Thus, the overall engineering process may be accessi- 
ble to a general category of users, a next lower level 
may be accessible to users involved specifically in the 
associated subprocess(es), and soon. The latter users 
may be maintenance officers, whereas the former only 
operate to design circuitry using the direct results. Many 
other distinction levels are feasible. 

Such method is readily implementable on a medium 
scale computer, such as a Digital Equipment Corpora- 
tion VAX-computer or the like. Alternative vehicles may 
be Apollo-type workstations now being manufactured by 
a subsidiary of Hewlett-Packard Corporation and linked 
in a computer network. 

In particular, advantageously the product describ- 
ing data may be electronic engineering data as ex- 
plained earlier. Alternatively, the product may be a me- 
chanical engineering product, a software engineering 
product, or the engineering product may itself be an en- 
gineering process. 

Advantageously, in a method as described supra, 
one or more feedback links are added to said first direct- 
ed-acyclic-graph, thereby transforming said first direct- 
ed-acyclic-graph into a generalized directed graph ex- 
hibiting cycles, whereby each feedback link, having ex- 
actly one source flow node and exactly one destination 
flow node, represents the fact that the product describ- 
ing data generated by an execution of said flow node 
can optionally be used as input for the execution of said 
destination flow node, thereby providing the capability 
of modifying the latter product describing data an arbi- 
trary number of times. This allows for a powerful iteration 
feature. 

BRIEF DESCRIPTION OF THE DRAWING 

The invention will be explained hereinafter by way 
of disclosing a non-limitative preferred embodiment 
such as disclosed in and by the appended Figures 
wherein: 

Figure 1 is a sample flow map showing tools and 
data useage; 

Figure 2 is a sample derivation graph for the flow 
graph of Figure 1 ; 

Figure 3 is an entity/relationship diagram of an ele- 
mentary database structure; 



Figure 4 is a similar diagram of a more extensive 
database structure; 

Figures 5, 6 represent two accessing mechanisms. 

5 DESCRIPTION OF A PREFERRED EMBODIMENT 

Figure 1 is a sample flow map showing tools and 
data useage. Data flows from left to right in this notation. 
In this example, blocks 20, 22.. 30 represent tools. Ex- 

10 amples of such tool functions have been given under A- 
G, supra, fora silicon compiler. In other engineering sys- 
tems, corresponding subprocesses would be obvious to 
the person of average skill. Generally, the tool itself is a 
computer program for effecting such tool function. Each 

is run of a tool may generate an instance of the represen- 
tation type following the tool in question in the Figure. 
Each tool may generate many kinds and versions of the 
same representation type, for example, in that eliminat- 
ing a bug or problem at a particular level would lead to 

20 corresponding different instances at each next following 
level in the lineage. Any instance, if applicable, may be 
of one alternative type of a set of types, for example, 
either before or after the problem has been removed. 
Moreover, any tool itself may yield instances that have 

25 different character, for example in that the partial results 
are classified into disjunct representations or results. 
Now, blocks 32.. 42 represent such instances. Thus, run- 
ning of tool 20 generates representations of the type 
symbolized by block 32. Running of tool 28 generates 

30 representations of the type symbolized by block 40. For 
simplicity, each running or execution of the same tool is 
presumed to generate only a single category of repre- 
sentation. Alternatively, such blocks 32..42 are pre- 
sumed to contain all representations produced by the 

35 flow caused by running its associated tool. Examples 
are that a particular tool used in CAD of VLSI-circuitry 
may produce either a schematic or a net-list or both each 
time the tool is executed. A schematic is a two-dimen- 
sional drawing showing subsystems as blocks plus their 

40 interconnections in the form of lines. A net-list gives, 
starting from a first sub-system interconnection pin all 
other pins (on the same or on another sub-system) to 
which the former pin is connected. 

Another example would be that a simulator tool pro- 

45 duces both an output waveform and an ASCII-coded 
character log file. Which one of the latter two be needed, 
is entirely determined by the selected viewing tool so 
that the details of the system are transparent to a user. 
Hereinafter, the combination of a tool block and its next- 

50 following output representational block is made into a 
node of a derivational first directed -acyclic-graph (flow- 
graph). A set of output representations produced by a 
single tool run is regarded hereinafter as a single entity, 
regardless of their accidental representations. Physical- 

55 ly, such multiple representations may thereafter be dis- 
tributed among multiple files, each pertaining to an as- 
sociated respective node. It should be noted that the dis- 
tinction between different representations is determined 
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by convention and technology, rather than by essence 
or principle. Likewise, Figure 1 may be changed in that 
the various data representations of running a particular 
tool be each assigned a given box, e.g. in that box 36 
had been divided into box 36A t leading exclusively to 
tool box 28, and another box 36B leading exclusively to 
tool box 30 (assuming that each of the latter tools need 
only a single data representation, which would be 
unique and mutually exclusive between tool boxes 28, 
30). It should be noted that Figure 1 should show all 
items and links with respect to the tools shown. Thus, 
tool 20 only outputs to block 32. Tool 24 exclusively 
feeds on data from that in block 32 and exclusively out- 
puts to block 36. Now, Figure 1 mathematically is a tree. 
Alternatively, the graph could have two source nodes 
linking to a single destination node. Instead of source 
node 24/36 linking by respective links to destination 
nodes 28/40, 30/42, in another circumstance both 
nodes 22/34 and 24/36 could as source nodes be linked 
to destination node 28/40. In this way a generalized di- 
rected-acyclic-graph would be procuded. In a database 
representation the linking could be by tethering pointers 
in the data pertaining to a particularllow node. The 
pointer may be an address, a logical name, or some oth- 
er entity, and would distinguish between a source flow 
node and a destination flow node in an elementary way 

Figure 2 shows a sample data derivation graph 
which might occur, given the flow graph of Figure 1 . No 
tools are shown. Each letter in Figure 2 represents an 
instance of an associated representation in Figure 1. 
Thus, there are two instances A of representation 32, 
four instances B of representation 34, four instances C 
of representation 36, and nine instances of representa- 
tion 40. Tools 26, 30 were not used. In the data structure 
of Figure 2, each derived instance must remember its 
father instance. Additionally, each father instance (C) 
may remember every son instance (E) referring to that 
father. In particular applications, especially in electronic 
engineering, each link between a particular father in- 
stance and a particular son instance may remember the 
options of the tool and the particular circumstances of 
the particular execution of that tool which created the 
associated instance of the representation in question. 
Thus, also Figure 2 shows a directed acyclic graph. 

On a specific technical level, the tools and data gen- 
erated thereby may be as follows for a VLSI CAD envi- 
ronment: 

20: schematic editor, produces schematic 32 
22: lay-out processor which produces lay-out 34 
24: simulator module produces simulation result 36 
26: postprocessor produces one or more tapes that 

could be fed into a plotter or the like (38) 
28: viewer module 

30: read log file which may contain error messages 
of errors incurred in simulation, or other data. 

By way of simplification, the graph of Figure 2, like 



the one of Figure 1 , is a tree, which, in a similar way 
could be a more generalized directed-acyc lie-graph. 
Furthermore, it could as an alternative to an electronic 
engineering process, relate to a mechanical engineer- 

5 ing process, a software engineering process, or the de- 
velopment of a process itself, the latter process then be- 
ing useable for manufacturing, or for developing one of 
the earlier described products of electrical, mechanical 
or software engineering. In a mechanical engineering 

io process, successive analysis steps could relate to kin- 
ematic analysis, structural analysis, and styling. In soft- 
ware engineering, a hierarchy of programs, program 
modules, and routines may be detailed in successive 
steps, in designing a process, input commodities, inter- 
ns mediate buffering and critical time paths may be detailed 
in successive steps. The present invention in each of 
these cases would provide easy accessing and organ- 
izing of the product describing data. 

Figure 3 shows the logical structure of the data used 

20 by a preferred elementary embodiment of the present 
invention. As is common practice in describing database 
designs, the data structure is described at the entity type 
level (rathlSrSiarTe^rty instance level) and at the rela- 
tionship type level. Thus, any single symbol, such as a 

25 box or a diamond, explained hereinafter, can corre- 
spond to an arbitrary number 1, 2... of database in- 
stances of that particular type. 

The described logical data structure can be convert- 
ed into a physical data structure (records, tables, at- 

30 tributes, pointers, etcetera) and augmented with means 
for reading, writing, updating, managing, and displaying 
the data in completely conventional ways. 

It should be noted that in a typical implementation 
of this or any other embodiment of the invention, these 

35 structures will be supplemented with additional struc- 
tures dealing with the various functional extensions 
without departing from the present inventive concept. 
Such additional structures may be, for example, (parts 
of) hierarchies used in describing the design data or in- 

40 formation, characterizing the allowed or selected invo- 
cation options for individual flow nodes. Form the logical 
data organization shown, the physical organization, 
such as logical/physical addressing, labeling, referenc- 
ing between records, displaying, inputting, outputting 

45 and various other physical-directed operations may be 
effected in completely conventional way. Of course, the 
structures shown are only minute examples of databas- 
es that may exhibit extreme degrees of complexity and 
massive storage requirements without departing from 

50 the present inventive concept. In particular, Figure 3 
shows an entity/relationship diagram defining the struc- 
ture of an elementary database for storing both the flow 
map information and the administrative data about the 
product describing data being managed as required by 

55 the method of this invention. The boxes represent entity 
types, the diamonds represent relationship types be- 
tween the connected entity types and the labels "1 " and 
"M^'many" along the connections between diamonds 
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and boxes provide cardinality information about the as- 
sociated relationship types. For more information on da- 
tabase schemas in general and the Entity/Relationship 
notation in particular, see "An Introduction to Database 
Systems", Volume 1, C.J. Date, Addison-Wesley, 1986 
(4th edition). 

Block 50 represents engineering sub-processes 
which require and/or produce product describing data. 
As explained, only a single box is shown, which can rep- 
resent multiple instances. These subprocesses are 
linked among each other by dependence flow links (52), 
thereby forming a data flow graph of the engineering 
process. Each dependence flow link (52) is associated 
via relationships 60 and 62 with two different instances 
of the engineering sub-process (50) entity type, thereby 
respectively representing the source and destination of 
the flow link. Together, elements 50, 52, 60 and 62 form 
a directed-acyclic-graph representing data flow be- 
tween the various engineering subprocesses. Again for 
simplicity, only two relationships 60,62 have been 
shown, in that a subprocess can either be at a source 
end of the flow link in question or at the destination end 
without any third possibility being allowed here. The car- 
dinality M of the link attachments (M) means that there 
can be many identical type links per subprocess. 

Block 54 represents the data set generated by each 
execution of a particular engineering subprocess (50). 
Block 54 may again represent many instances. Rela- 
tionship 64 links each data set to the engineering sub- 
process (50) by which it was generated. The cardinality 
M (the different letters M can have completely different 
values in practice) indicates that one particular process 
may in principle be able to generate many data sets. 
The data sets 54 are linked via derivation links (56). 
Each derivation link (56) is associated via relationships 
66 and 68 with two different instances of the data set 
entity type 54 which respectively represent the source 
and destination of the derivation link (56). Together, el- 
ements 54, 56, 66 and 68 form a directed-acyclic-graph 
representing the usage of existing data sets in the gen- 
eration of new data sets. This graph thus provides infor- 
mation about both the interrelationships between the 
various data sets (54) and about the history of the cor- 
responding engineering subprocesses (50). 

The final relationship 70 associated each derivation 
link 56 with exactly one flow link 52, thereby represent- 
ing how the derivation link between two data sets is as- 
sociated with the flow of data between two engineering 
subprocesses. It is worth nothing that relationship 70 
serves to facilitate the maintainability of the database 
and can be omitted if the database integrity is main- 
tained by suitable algorithms whenever the database is 
updated. 

The information linking each data set entity (54) to 
the corresponding product describing data in a data 
storage system are not shown because this information 
depends on the physical and organizational details of 
the storage system and because this link can be imple- 



mented by any competent person familiar with database 
technology. Typically this would involve recording the 
network nodes, disks, directories, file names, etcetera 
of the product describing data for all data sets. 

5 Figure 4 shows an entity/relationship diagram de- 
fining the structure of a more extensive database for 
storing the fiow map information and the administrative 
data about the product describing data being managed. 
Compared to the previous Figure, Figure 4 contains ad- 

10 ditional information about how the product describing 
data is partitioned into representations (e.g. "netlist", 
"schematic", "log file") in an electronic engineering en- 
vironment. Although the basis structure of Figure 4 is 
comparable to Figure 3 and as such would require little 

is explanation, various additions and refinements produce 
improved facilities and properties. 

Block 72 represents engineering subprocesses 
which each require a set of input representations in or- 
der to produce a set of output representations. Repre- 

20 sentations are fed into a subprocess via input slots (74). 
Representations generated by the execution of a sub- 
process become available at output slots (80). Relation- 
ship types 84 and 88 respectively link each input and 
output slot to the corresponding engineering subproc- 

25 ess (72). Relationship type 86 indicates which input 
slots (74) are connected to which output slot (80). To- 
gether, elements 72, 74, 80, 84, 86 and 88 form a data 
flow model indicating how the various engineering sub- 
processes make use of the representations generated 

30 by other engineering subprocesses. 

Block 78 represents an execution of the engineer- 
ing subprocess (72) to which it is linked via relationship 
type 94. Each execution (78) of an engineering subproc- 
ess generates an number of representations (82) to 

35 which it is linked via relationship type 98. Each of these 
representations is associated with the output slot (80) 
by means of which it was produced via relationship type 
92. Each execution (78) of an engineering subprocess 
(72) uses the set of representations (82) to which it is 

40 indirectly linked via relationship 1 00, the representation 
usage entity 76 and relationship 96. From the inverse 
point of view, each representation 82 is used by the set 
of engineering subprocess executions (78) to which it is 
indirectly linked via relationship 96, the representation 

45 usage entity (76) and relationship 100. Each represen- 
tation usage entity (76), representing the usage a given 
representation (82) within a particular engineering sub- 
process execution (78), is associated with the input slot 
(74) in which it was used via relationship 90. Together, 

50 elements 76, 78, 82, 96, 98 and 100 describe how the 
representations being managed by the system are in- 
terrelated through derivation as well as their generation 
history. 

As in Figure 3, the information linking each repre- 
ss sentation (82) to the corresponding product describing 
information in a data storage system is not shown be- 
cause this information depends on the details of the stor- 
age system and because this link can be implemented 
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by any competent person familiar with database tech- 
nology. 

In addition to the above, tools may occur in quite 
simple form, in that they require one upstream tool to 
have been executed and thereupon allow one down- 
stream tool to be excecuted. A more complicated tool 
may have two inputs and one output. Such tools may be 
serialized in that the output of the first operates as one 
of the two inputs of the second. Collectively, they would 
then function as a three-input, two-output composite 
tool. On the other hand, the output of a preceding tool 
may be used in two succeeding tools in parallel. The 
latter could have their outputs, in turn, feed only one sin- 
gle output tool. The combination of the four last-men- 
tioned tools could, alternatively be represented as a sin- 
gle-input-single-output (compound) tool. 

BACKGROUND CONSIDERATIONS 

The method provides a model of the data flow be- 
tween the various engineering activities needed to pro- 
duce and validate the data This model is used to store 
and retrieve the generated data: the data is stored ac- 
cording to a new data schema (logical data structure) 
and retrieved using a new browsing/access technique. 
An extension of the invention involves using the data 
flow information to determine the user's privileges (e.g. 
visibility, usage and update rights) with respect to the 
data being managed. 

The new insight on which the invention is based can 
be clarified by dividing the control information which the 
system needs into three distinct levels: 

1) "Flow-type definition lever 

This part of the data schema describes which pro- 
grams/subprocess steps are available when setting 
up one or more engineering processes. In practice 
this level should know which programs are availa- 
ble, how many "inputs" and "outputs" each program/ 
step has (optionally with typing information). Exam- 
ple: a format conversion program accepts one input 
file and uses this to produce one output file of a dif- 
ferent type. In Figures 3, 4, for reasons of clarity this 
level has not been visualized. 

2) "Flow-map definition level" 

This part of the data schema describes how the var- 
ious flow-types (defined in level 1 ) are interconnect- 
ed, thereby forming a map of a particular engineer- 
ing process. The typing information of level 1 can 
be used to check the interconnections of level 2. 
This level corresponds to the left-hand halves of 
Figures 3, 4. 

3) "Data and flow run level" 

This part of the data schema describes individual 
runs (executions) of flows (as defined in level 2) 
along with the data these produced. Thus level 3 is 
basically a database about the units of data pro- 
duced by the engineering process while simultane- 



ously acting as a record of all major activities with 
this process. The flow-map information of level 2 
can be used as a very rigorous form of type check- 
ing: it can be used to prevent the running of tools 
s on inappropriate data units. This level corresponds 
to the right-hand halves of Figures 3, 4. 

Notably, levels 1 and 2 of the resulting database are 
respectively filled when the system is configured while 
to level 3 stores data about what is happening during the 
design process being supported. 

Our invention is different from existing solutions in 
the way it uses a data flow model of the data generating 
process as the primary source of information about the 
f5 nature of the data generated by the process itself. Over- 
all advantages of this general principle and our particu- 
lar technique are with respect to coherence: 

The system provides close integration between 
functionality regarding the automation and control of the 
engineering process on the one hand and the function- 
ality regarding the management of the generated data 
on the other hand. 

Furthermore, from a pragmatic point of view: 

* less effort needed to configure a system, 

* less data need to be supplied about what the indi- 
vidual units of data represent, 

* user interface can present data to users in a way 
consistent with the activities which are relevant at 
that time. 

Example: the code needed to integrate an individual 
tool into the system can be limited to what is re- 
quired to handle idiosyncracies of the tool, issues 
common to all tools are handled by "filling tables" 
describing the tool and its links to its environment. 

Accuracy: 

The system uses a more accurate model of the sig- 
nificance c.q. structure of the data being managed 
than existing systems. From a pragmatic point of 
view the concepts with which the system communi- 
cates to the user are more powerful and close to the 
way the user views the data (human factors issue). 
The accuracy allows the system to provide more 
functionality, because the system knows more 
about what the data being managed "means" to the 
user. 

Example: existing systems use the concept of "ver- 
sioning" for different situations which should actu- 
ally be also differently. In effect, the present method 
and system provides the facility for such differenti- 
ation. 

Flexibility: The system can handle a wider variety 
of engineering processes than existing systems. 
Example: the access/browsing technique works 
equally well on data describing the product itself as 
on auxiliary data, e.g. test data. 
Simplicity: The system uses fewer internal concepts 
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It is possible that output of an engineering subproc- 
ess is used as an input of the same subprocess. Such 
a subprocess may be called an editor. An example is a 
simple text editor, in which the text, produced in a pre- 
vious edit-session, can be used in a new edit-session to 
produce a modified version of the original text. Likewise, 
various other types of data editors may be used. 

Generally, the data flow map of the engineering 
process forms a directed graph without loops. However, 
if the engineering process contains an editor the direct- 
ed graph contains a loop. This loop requires special 
treatment to make it possible to execute an editor with- 
out input, in order to produce the first version of the out- 
put, thereby making the data flow in the loop optimal. 

Various other useful features are: the invention al- 
lows the nesting of flows. Although this might appear a 
trivial issue, it allows for the construction of improved 
user interfaces. For example, in a preprocessor -tool- 
postprocessor sequence, the tool becomes hidden by 
the automation. Particular advantages of the use of the 
invention are that project organization is facilitated, per- 
son-to-person communication is done by making the da- 
ta communicated visible, and also project management 
on a time/data/resource/manpower level is made easier. 

Figures 5, 6 illustrate two accessing mechanisms. 
In Figure 5, line 100 indicates the dichotomy between 
flow graph (top) and data graph (bottom). In the flow 
graph, flow nodes 102, 104 are directly linked by flow 
link 1 06. Here flow node 1 02 is the source and flow node 
104 is the destination. Flow node 108 is a further source 
node to flow node 104 by indirect linkeage which has 
been shown by interrupted line 110. This latter linkeage 
may or may not include flow node 102. Flow node 102 
is referred to by three data nodes 112, 114, 116. Flow 
node 104 is referred to by three data nodes 118, 120, 
122. Flow node 108 is referred to by data nodes 124, 
126, 128. In accessing, a first subset of the data nodes 
is selected in that they must refer to flow node 104. It is 
possible to a priori not select all those data nodes, for 
example in that one or more data nodes contain a di- 
rectly detectable error. The latter have not been shown. 
As shown, the data nodes have a linkeage pattern that 
mimics the linkeage pattern of the flow nodes. Now two 
arbitrary further subsets of the data nodes are selected, 
one referring to flow node 108, one to flow node 102. 



For one reason or another, such as a directly detectable 
error, data node 11 2 is excluded from the auxiliary sub- 
set related to flow node 102. Now this is used to restrict 
the first subset of data nodes 1 1 8, 1 20, 1 22 by excluding 
data node 122 in that it has not both a directly linked 
data source node referring to flow node 102 and also a 
(n indirectly) linked data source node referring to flow 
node 108. The restriction to the final subset (118, 120) 
is shown by a broken line. In any more complicated 
structure, the selecting mechanism would operate in 
comparable manner; the only differences would be the 
number of elements in the various sets, the number of 
terms in the logical AN D-f unction combining the various 
auxiliary subsets, the depth of the linkeage pattern, and 
the various reasons leading to exclusion of elements of 
the respective sets. 

Whereas in Figure 5 the reasoning exploits the up- 
stream linkeage pattern, this is directed in the down- 
stream direction in Figure 6. Flow node 130 is directly 
linked as source node to destination flow node 1 32 and 
indirectly to destination flow node 134. Again, a part or 
whole of the indirect path may lead through flow node 
1 32. For selecting, first a subset referring to flow node 
130 is selected, to wit, data nodes 136, 138, 140. Flow 
node 1 32 is referred to by data nodes 1 42, 1 44, both of 
which are selected in an auxiliary subset. Flow node 1 34 
is referred to by data nodes 146 (selected in its auxiliary 
subset) and 1 48 (not selected). In this case the final sub- 
set is restricted to data node 1 36, because of the exclu- 
sion of data node 148 (leads to exclusion of data node 
1 40) and the non-existence of two data nodes that would 
be linked as destination nodes to data source nodes 
138, 140. Also in this case, the linkage pattern may be 
much more complex. Both selection/restriction organi- 
zation of Figures 5, 6 may combine. The number of aux- 
iliary subsets may be one on only one side (either up- 
stream or downstream) or two (one upstream and one 
downstream) or combined. 

The database may comprise coupling between 
links, such as between data links 150, 152, 154, to flow 
link 106. 



Claims 

1 . A method for organizing and accessing product de- 
scribing data, generated and used by an engineer- 
ing process comprising multiple engineering sub- 
processes, said method comprising: 

a. providing a set of flow nodes, each individual 
flow node representing one of said subprocess- 
es; 

b. performing at least one flow node execution, 
which flow node execution represents a corre- 
sponding subprocess execution which thereby 
uses and/or generates respective part(s) of 
said product describing data; 



than an existing system which extend to provide 
comparable functionality. This tends to reduce de- 
velopment and maintenance costs for the system 
and potentially reduces the training effort for end- 
users. The system should be slightly faster for sim- s 
ilar reasons. 

Example: unlike previous systems, the technique 
does not need to maintain separate sets of informa- 
tion for describing the classification of the data and 
for describing the history of the engineering proc- 10 
ess. These are handled by the same set of con- 
cepts. 
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c. providing a data flow model of the engineer- 
ing process by linking said flow nodes to form 
a first directed-acyclic-graph of which each flow 
link, by connecting one source flow node to one 
destination flow node, represents as fact that s 
each execution of said destination flow node re- 
quires partial or complete usage of product de- 
scribing data generated by execution of said 
source flow node; 

d. providing a set of data nodes, each individual 10 
data node referencing one flow node for so rep- 
resenting one unique individual execution of 

the flow node so referenced and consequently 
also representing the product describing data 
generated by the unique individual flow node is 
execution; 

e. providing a model of the product describing 
data used and generated by the engineering 
process by linking said data nodes to form a 
second directed-acyclic-graph of which each 20 
data link, by connecting one source data node 

to one destination data node, represents the 
partial or complete usage of the product de- 
scribing data represented by said source data 
node for generating the product describing data 25 
represented by said destination data node; 

f. selecting from the set of data nodes a first 
subset of data nodes by selecting one first par- 
ticular flow node which restricts said first subset 

of data nodes to those data nodes which refer- 30 
ence said first particular flow node, 

g. selecting a plurality of auxiliary subsets of da- 
ta nodes, each auxiliary subset comprising data 
nodes which reference one respective further 
particular flow node, that is directly or indirectly 35 
linked as source flow node to said first particu- 
lar flow node by respective associated flow link 

or links in said first directed-acyclic-graph, 
thereby reducing said first subset of data nodes 
to form a final set of data nodes comprising only 40 
those data nodes in the first subset for which 
the engineering subprocess executions repre- 
sented thereby directly or indirectly had used 
the product describing data represented by one 
of the data nodes in each of the plurality of aux- *s 
iliary subsets of data nodes; 

h. accessing the product describing data repre- 
sented by said final subset of data nodes using 
mapping information relating individual data 
nodes to product describing data residing with- so 
in a data storage system. 

A method as in Claim 1 , further comprising the step 
of: 

g\ selecting a plurality of second auxiliary subsets ss 
of data nodes, each second auxiliary subset com- 
prising data nodes which reference one respective 
second particular flow node, that is directly or indi- 



rectly linked as destination flow node to said first 
particular flow node by respective associated fur- 
ther flow link or links in said first directed-acyclic- 
graph, thereby reducing said first subset of data 
nodes to a second final set of data nodes in that 
said second final subset of data nodes comprises 
only those data nodes in the first subset for which 
the engineering subprocess executions represent- 
ed thereby directly or indirectly had been used for 
generating the product describing data represented 
by one of the data nodes in each of the plurality of 
second auxiliary subsets of data nodes. 

3. A method as in Claim 1 or 2, wherein each particular 
data link is coupled to exactly one flow link in that 
the product describing data represented by each 
end node of said data link originate from an execu- 
tion of the subprocesses corresponding to the re- 
spective end nodes of the thereto coupled flow link. 

4. A method as in Claim 1 , 2 or 3, wherein the first 
directed-acyclic-graph is extended to an extended 
directed-acyclic-graph with information about the 
way in which the product describing data, produced 
and used, respectively, by executions of the engi- 
neering subprocesses is partitioned into units and 
wherein the second directed-acyclic-graph is ex- 
tended with information mapping said individual 
units of data residing within a storage system onto 
elements of the second directed-acyclic-graph. 

5. A method as claimed in Claim 4, wherein the flow 
nodes within the extended directed-acyclic-graph 
are provided with additional typing information rep- 
resenting the type of engineering subprocess of 
which they are an instance thereby allowing the us- 
age of the flow nodes in the extended directed-acy- 
clic-graph to be checked against said typing infor- 
mation. 

6. A method as in any of Claims 1 to 5, wherein a fur- 
ther subset of the flow nodes of the first directed- 
acyclic-graph is provided with information pertain- 
ing to a location and method of invocation of exe- 
cutable programs corresponding to the respective 
elements of said subset, thereby allowing the infor- 
mation in the first directed-acyclic-graph to be used 
to automate and/or support the execution of said ex- 
ecutable programs. 

7. A method as in any of Claims 1 to 6, wherein an 
additional type of link is introduced interconnecting 
flow nodes in the first directed-acyclic-graph there- 
by representing non -mandatory use of product de- 
scribing data by executions of the engineering sub- 
process corresponding to the destination node of 
said type of links. 
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8. A method as in any of Claims 1 to 7, wherein the 
first directed-acyclic-graph forms a hierarchical 
model of the engineering process by linking nodes 
therein representing either individual engineering 
subprocesses or subgraphs of interlinked engineer- $ 
ing subprocesses. 

9. A method as in Claim 8, wherein hierarchical de- 
scription of the engineering process limits the ac- 
cessibility and visibility of product describing data 10 
generated by the execution of flow nodes belonging 

to a particular level of the hierarchy to those users 
of the system with appropriate privileges for said 
particular level. 

15 

10. A method as claimed in any of Claims 1 to 9, where- 
in feedback link means are added to said first di- 
rected-acyclic-graph, thereby transforming said 
first directed-acyclic-graph into a generalized di- 
rected graph exhibiting one or more cycles, where- 20 
by each feedback link, having exactly one source 
flow node and exactly one destination flow node, 
represents the fact that the product describing data ^ 
generated by an execution of said flow node can 
optionally be used as input for the execution of said 25 
destination flow node, thereby providing the capa- 
bility of modifying the latter product describing data 

an arbitrary number of times. 

30 

Patentanspruche 

1 . Verf ahren zur Organisation von und zum Zugriff auf 
produktbeschreibende Daten, die durch einen tech- 
nischen ProzeB, welch er mehrere technische Teil- 35 
prozesse umfaGt, erzeugt und benutzt werden, wo- 
bei das genannte Verfahren folgendes umfafit: 

a. Schaffen einer Gruppe von Ablaufknoten- 
punkten, wobei jeder einzelne Ablaufknoten- 40 
punkt einen der genannten Teilprozesse dar- 
stellt; 

b. Durchfuhren von mindestens einer Ablauf- 
knotenpunkt-Ausfuhrung, wobei die Ausfuh- 
rung des Ablaufknotenpunktes eine entspre- 45 
chende Ausfuhrung eines Teilprozesses dar- 
stellt, die dadurch entsprechende Teile der ge- 
nannten produktbeschreibenden Daten be- 
nutzt und/oder erzeugt; 

c. Schaffen eines DatenfluGmodells des tech- 50 
nischen Prozesses durch Verbinden der ge- 
nannten Ablaufknotenpunkte, um eine erste 
gerichtete azyklische Graphik zu bilden, von 
der jede Ablaufverbindung durch Verbinden ei- 
nes Quellen-Ablaufknotenpunktes mit einem 55 
Ziel-Ablaufknotenpunkt als Tatsache darstellt, 
daB jede Ausfuhrung des genannten Ziel-Ab- 
laufknotenpunktes die teilweise oder komplette 
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Nutzung von produktbeschreibenden Daten er- 
fordert, die durch die Ausfuhrung des genann- 
ten Quellen-Ablaufknotenpunktes erzeugt wur- 
den. 

d. Schaffen einer Gruppe von Daten knot en- 
punkten, wobei sich jeder einzelne Datenkno- 
tenpunkt auf einen Ablaufknotenpunkt bezieht, 
um somit eine einzigartige einzelne Ausfuh- 
rung des derart verwiesenen Ablaufknoten- 
punktes darzustellen und daher auch die pro- 
duktbeschreibenden Daten darzustellen, die 
durch die einzigartige einzelne Ausfuhrung des 
Ablaufknotenpunktes erzeugt wurden; 

e. Schaffen eines Mode I Is der durch den tech- 
nischen ProzefJ benutzten oder erzeugten pro- 
duktbeschreibenden Daten durch Verbinden 
der genannten Datenknotenpunkte, um eine 
zweite gerichtete azyklische Graphik zu bilden, 
bei der jede Datenverbindung durch Verbinden 
eines Quellen-Datenknotenpunktes mit einem 
Ziel-Datenknotenpunkt die teilweise oder kom- 
plette Nutzung der produktbeschreibenden Da- 

^ ' ten darstellt, die durch den genannten Quellen- 
Datenknotenpunkt zum Erzeugen der produkt- 
beschreibenden Daten dargestellt werden, 
welche durch den genannten Ziel-Datenkno- 
tenpunkt dargestellt werden; 

f. Auswahlen einer ersten Teilgruppe von Da- 
tenknotenpunkten aus der Gruppe von Daten- 
knotenpunkten durch Wahlen eines ersten be- 
stimmten Ablaufknotenpunktes, der die ge- 
nannte erste Teilgruppe von Datenknotenpunk- 
ten auf diejenigen Datenknotenpunkte be- 
grenzt, die auf den genannten ersten bestimm- 
ten Ablaufknotenpunkt verweisen; 

g. Auswahlen einer Vtelzahl von zusatzlichen 
Teilgruppen von Daten knotenpunkt en, wobei 
jede zusatzliche Teilgruppe Datenknotenpunk- 
te enthalt, die auf einen weiteren bestimmten 
Ablaufknotenpunkt verweisen, der uber ent- 
sprechende zugehdrige Ablaufverbindungen 
oder Verbindungen in der ersten genannten ge- 
richteten azyklischen Graphik direkt oder indi- 
rekt als Que lien -Ablaufknotenpunkt mit dem 
genannten ersten bestimmten Ablaufknoten- 
punkt verbunden ist, wodurch die erste Teil- 
gruppe von Daten knotenpunkten reduziert 
wird, um eine letzte Gruppe von Datenknoten- 
punkten zu bilden, die nur diejenigen Daten- 
knotenpunkte in der ersten Teilgruppe enthalt, 
fur die die Ausfuhrungen des technischen Teil- 
prozesses, die hierdurch direkt oder indirekt 
dargestellt werden, die produktbeschreiben- 
den Daten benutzt haben, welche durch einen 
der Datenknotenpunkte in jeder Teilgruppe aus 
der Vielzahl der zusatzlichen Teilgruppen von 
Datenknotenpunkten dargestellt werden; 

h. Zugreifen auf die durch die genannte letzte 
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Teilgruppe von Datenknotenpunkten darge- 
stellten produktbeschreibenden Daten mit Hilfe 
von Abbildungs-lnfomnationen, die einzelne 
Datenknotenpunkte mit produktbeschreiben- 
den Daten in Zusammenhang bringen, welche s 
sich in einem Daten speichersystem befinden. 

2. Verfahren nach Anspruch 1 , das weiterhin den fol- 
genden Schritt umfaGt: 

g\ Wahlen einer Vielzahl von zweiten zusatziichen io 
Teilgruppen von Datenknotenpunkten, wobei jede 
zweite zusatzliche Teilgruppe Datenknotenpunkte 
enthalt, die auf einen entsprechenden zweiten be- 
stimmten Ablaulknotenpunkt verweisen, der Ober 
eine zugehorige weitere Ablaufverbindung Oder is 
Verbindungen in der genannten ersten gerichteten 
azyklischen Graphik direkt Oder indirekt als Ziel-Ab- 
laufknotenpunkt mit dem genannten ersten be- 
stimmten Ablaufknotenpunkt verbunden ist, wo- 
durch die genannte erste Teilgruppe von Datenkno- 20 
tenpuntcten auf eine zweite letzte Gruppe von Da- 
tenknotenpunkten reduziert wird t da die genannte 
zweite letzte Teilgruppe von Datenknotenpunkten 
nur diejenigen Datenknotenpunkte in der ersten 
Teilgruppe enthalt, fur die die Ausfuhrungen des 25 
technischen Teilprozesses, die dadurch direkt oder 
indirekt dargestelltwerden, benutzt wurden, urn die 
produktbeschreibenden Daten zu erzeugen, die 
durch einen der Datenknotenpunkte in jeder zwei- 
ten zusatziichen Teilgruppe der Daten knoten punk- 30 
te aus der Vielzahl dieser Teilgruppen dargestellt 
werden. 

3. Verfahren nach Anspruch 1 oder 2, wobei jede be- 
stimmte Datenverbindung mit genau einer Ablauf- 35 
verbindung gekoppelt ist, da die produktbeschrei- 
benden Daten, die durch jeden Endknotenpunktder 
genannten Datenverbindung dargestellt werden, 
von einer Ausfuhrung der Teilprozesse stammen, 

die den jeweiligen Endknotenpunkten der hiermit 40 
gekoppelten Ablaufverbindung entsprechen. 

4. Verfahren nach Anspruch 1 , 2 oder 3, wobei die er- 
ste gerichtete azyklische Graphik erweitert wird auf 
eine erweiterte gerichtete azyklische Graphik mit 45 
Informationen Ober die Art, in der die produktbe- 
schreibenden Daten, die durch die Ausfuhrungen 
der technischen Teilprozesse erzeugt bzw. benutzt 
werden, in Einheiten aufgeteitt werden, und wobei 

die zweite gerichtete azyklische Graphik urn Infor- so 
mationen erweitert wird, die die genannten einzel- 
nen Dateneinheiten in einem Speichersystem auf 
Elemente der zweiten gerichteten azyklischen Gra- 
phik abbilden. 

55 

5. Verfahren nach Anspruch 4, wobei die Ablaufkno- 
tenpunkte innerhalb der erweiterten gerichteten 
azyklischen Graphik mit zusatziichen Typ-informa- 



tionen versehen werden, die den Typ des techni- 
schen Prozesses darstellen, von dem sie ein Bei- 
spielfall sind, wodurch die Nutzung der Ablaufkno- 
tenpunkte in der erweiterten gerichteten azykli- 
schen Graphik anhand der genannten Typ-lnforma- 
tionen gepruft werden kann. 

6. Verfahren nach einem der Anspruche 1 bis 5, wobei 
eine weitere Teilgruppe von Ablaufknotenpunkten 
der ersten gerichteten azyklischen Graphik mit In- 
formationen versehen wird, die sich auf einen Ort 
und eine Methode zum Aufrufen von ausfuhrbaren 
Programmen beziehen, die den jeweiligen Elemen- 
ten der genannten Teilgruppen entsprechen, wo- 
durch die Informationen in der ersten gerichteten 
azyklischen Graphik benutzt werden konnen, urn 
die Ausfuhrung der genannten ausfuhrbaren Pro- 
gramme zu automatisieren und/oder zu unterstut- 
zen. 

7. Verfahren nach einem der Anspruche 1 bis 6, wobei 
ein zusatzlicher Verbindungstyp eingefuhrt wird, 
der die Ablauf knotenpunkte in der ersten gerichte- 
ten azyklischen Graphik miteinander verbindet und 
dadurch die nicht-obligatorische Nutzung von pro- 
duktbeschreibenden Daten durch Ausfuhrungen 
des technischen Teilprozesses darstellt, die dem 
Zielknotenpunkt des genannten Verbindungstyps 
entsprechen. 

8. Verfahren nach einem der Anspruche 1 bis 7, wobei 
die erste gerichtete azyklische Graphik ein hierar- 
chisches Modell des technischen Prozesses bildet, 
indem die Knotenpun kte darin, die entweder einzel- 
ne technische Teilprozesse oder Teilgraphiken von 
miteinander verbundenen technischen Teilprozes- 
sen darstellen, verbunden werden. 

9. Verfahren nach Anspruch 8, wobei die hierarchi- 
sche Beschreibung der technischen Prozesse die 
Zuganglichkeit und Sichtbarkeit der produktbe- 
schreibenden Daten, die durch die Ausfuhrung von 
Ablaufknotenpunkten erzeugt wurden, weiche zu 
einer bestimmten Hierarchie-Ebene gehdren, auf 
diejenigen Benutzer des Systems begrenzt, die 
Ober geeignete Befugnisse fur die genannte be- 
stimmte Ebene veriugen, 

1 0. Verfahren nach einem der Anspruche 1 bis 9, wobei 
Ruckkopplungs-Verbindungsmittel zu der genann- 
ten ersten gerichteten azyklischen Graphik hinzu- 
gefugt werden, wodurch die genannte erste gerich- 
tete azyklische Graphik in eine verallgemeinerte 
gerichtete Graphik umgewandelt wird, die einen 
oder mehrere Zyklen aufweist, wodurch jede Ruck- 
kopplungsverbindung mit genau einem Quellen- 
Ab la uf knoten punkt und genau einem Ziel-Ablauf- 
knotenpunkt die Tatsache darstellt, da3 die durch 
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eine Ausfuhrung des genannten Ablaufknoten- 
punktes erzeugten produktbeschreibenden Daten 
optional als Eingabe fur die Ausfuhrung des ge- 
nannten Ziel-Ablaufknotenpunktes benutzt werden 
konnen, wodurch die Moglichkeit geschaffen wird, $ 
die letztgenannten produktbeschreibenden Daten 
beliebig oft zu andera 

R even di cat ions M> 

1. Precede pour organiser et acceder a des donnees 
decrivant des p rod u its, generees et utilisees par un 
processus d'ingenierie comprenant de nombreux 
sous-processus d'ingenierie, (edit precede compre- is 
nant les eta pes visant a : 

a. fournir un ensemble de noeuds de flux, cha- 
que noeud de flux individuel representant un 
desdits sous-processus; 20 

b. effectuer au moins une execution de noeud 
de flux, laquelle execution de noeud de flux re- 
presente une execution d'un sous-processus 
correspondant qui utilise et/ou genere des lors 
une (des) partie(s) respective(s) desdites don- 25 
nees decrivant des produits; 

c. fournir un modele de flux de donnees du pro- 
cessus d'ingenierie en reliant lesdits noeuds de 
flux afin de former un premier graphe acyclique 
oriente dont chaque liaison de flux, en connec- 30 
tant un noeud de flux source a un noeud de flux 

de destination, represente le fait que chaque 
execution dudit noeud de flux de destination re- 
quiert 1'utilisation partielleou complete des don- 
nees decrivant des produits, generees par 35 
I'execution dudit noeud de flux source; 

d. fournir un ensemble de noeuds de donnees, 
chaque noeud de donnees individuel faisant re- 
ference a un noeud de flux qui represente une 
execution individuelle unique du noeud de flux 40 
ainsi designe et, par consequent, representant 
egalement les donnees decrivant des produits, 
generees par I'execution de noeud de flux indi- 
viduel unique; 

e. fournir un modele des donnees decrivant des *s 
produits utilisees et generees par le processus 
d'ingenierie en reliant lesdits noeuds de don- 
nees afin de former un deuxieme graphe acy- 
clique oriente dont chaque liaison de donnees, 

en connectant un noeud de donnees source a so 
un noeud de donnees de destination, represen- 
te 1'utilisation partielle ou complete des don- 
nees decrivant des produits, representees par 
I edit noeud de donnees source pour generer 
les donnees decrivant des produits repr6sen- ss 
tees par ledit noeud de donn6es de destination; 

f. seiectionner dans I'ensemble de noeuds de 
donn6es un premier sous-ensemble de noeuds 



de donnees en seiectionnant un premier noeud 
de flux particulier qui restreint ledit premier 
sous-ensemble de noeuds de donnees a ces 
noeuds de donnees qui font reference audit 
premier noeud de flux particulier; 

g. seiectionner une plurality de sous-ensem- 
bles auxiliaires de noeuds de donnees, chaque 
sous-ensemble auxiliaire comprenant des 
noeuds de donnees qui font reference a un 
autre noeud de flux de donnees particulier res- 
pectif, qui est relie directement ou indirecte- 
ment en tant que noeud de flux source audit 
premier noeud de flux particulier par une ou des 
liaisons de flux associees respectives dans le- 
dit premier graphe acyclique oriente, reduisant 
ainsi ledit premier sous-ensemble de noeuds 
de donnees afin de former un ensemble final 
de noeuds de donnees comprenant unique- 
merit les noeuds de donnees dans le premier 
sous-ensemble pour lesquels les executions 
de sous-processus d'ingenierie representees 
de la sorte directement ou indirectement ont uti- 
lise les donnees decrivant des produits, repre- 
sentees par un des noeuds de donnees dans 
chaque sous-ensemble auxiliaire de la plural it 6 
de sous-ensembles auxiliaires des noeuds de 
donnees, et 

h. acceder aux donn6es decrivant des produits 
representees par ledit sous-ensemble final de 
noeuds de donnees en mettant en correspon- 
dance I'information concernant des noeuds de 
donnees individuels avec des donnees decri- 
vant des produits residant dans un systeme de 
stockage de donnees. 

2. Procede suivant la revendication 1 , comprenant, en 
outre, l'6tape visant a : 

g'. seiectionner une plurality de deuxiemes 
sous-ensembles auxiliaires de noeuds de donnees, 
chaque deuxieme sous-ensemble auxiliaire com- 
prenant des noeuds de donnees qui font reference 
a un deuxieme noeud de flux particulier respectif, 
qui est relie directement ou indirectement en tant 
que noeud de flux de destination audit premier 
noeud de flux particulier par une ou des autres 
liaisons de flux associees respectives dans ledit 
premier graphe acyclique oriente, reduisant ainsi 
ledit premier sous-ensemble de noeuds de don- 
nees en un deuxieme ensemble final de noeuds de 
donnees par le fait que ledit deuxieme sous-ensem- 
ble final de noeuds de donnees com p rend unique- 
ment les noeuds de donnees dans le premier sous- 
ensemble pour lesquels les executions de sous- 
processus d'ingenierie representees de la sorte di- 
rectement ou indirectement ont ete utilisees pour 
generer les donnees decrivant des produits, repre- 
sentees par un des noeuds de donn6es dans cha- 
que sous-ensemble auxiliaire de la pluralite de 
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deuxiemes sous-ensembles auxiliaires de noeuds 
de donnees. 

3. ProcSdS suivant la revendication 1 ou 2, dans le- 
quel chaque liaison de donnees particuttere est $ 
couplee a exactement une liaison de flux par le fait 
que les donnees decrivant des produits, represen- 
tees par chaque noeud terminal de ladite liaison de 
donnees proviennent d'une execution des sous- 
processus correspondent aux noeuds terminaux io 
respectifs de la liaison de flux couplee a ces dernie- 
res. 

4. Procede suivant la revendication 1 , 2 ou 3, dans le- 
quel le premier graphe acyclique orients est Stendu is 
a un graphe acyclique oriente etendu par des infor- 
mations concernant la facon dont les donnSes dS- 
crivant des produits, produites et utilisSes, respec- 
tivement, par des executions des sous-processus 
d'ingSnierie sont reparties physiquement en unites 20 
et dans lequel le deuxieme graphe acyclique orien- 
ts est Stendu par des informations de mise en cor- 
respondence desdites unites individuelles de don- 
nees residant dans un systeme de stockage sur des 
elements du deuxieme graphe acyclique oriente. 25 

5. Procede suivant la revendication 4, dans lequel les 
noeuds de flux dans le graphe acyclique oriente 
etendu sont pourvus d'informations de typage sup- 
plementaires representant le type de sous-proces- 30 
sus d'ingenierie dont ils constituent un exemple, 
permettant de la sorte de comparer I'usage des 
noeuds de flux dans le graphe acyclique orients 
Stendu auxdites informations de typage. 

35 

6. ProcSdS suivant Tune quelconque des revendica- 
tions 1 a 5, dans lequel un autre sous-ensemble des 
noeuds de flux du premier graphe acyclique orients 
comprend des informations concernant un empla- 
cement et un procede d'appel des programmes 40 
exScutabies correspondants aux elements respec- 
tifs dudit autre sous-ensemble, permettant de la 
sorte d'utiliser les informations prSsentes dans le 
premier graphe acyclique oriente pour automatiser 
et/ou supporter ('execution desdits programmes 45 
exScutabies. 

7. Procede suivant Tune quelconque des revendica- 
ttons 1 a 6, dans lequel un type supplemental de 
liaison est introduit pour interconnecter des noeuds so 
de flux dans le premier graphe acyclique oriente, 
representant de la sorte une utilisation non prescrite 
des donnees decrivant des produits par des execu- 
tions du sous-processus d'ingenierie correspon- 
dent au noeud de destination dudit type de liaison, ss 

8. Procede suivant I'une quelconque des revendica- 
tions 1 a 7, dans lequel le premier graphe acyclique 



oriente constitue un modeie hierarchique des pro- 
cessus d'ingenierie en reliant des noeuds dans ce 
graphe representant soit des sous-processus d'in- 
genierie individuels, soit des sous-graphes de 
sous-processus d'ingenierie relies entre eux. 

9. Procede suivant la revendication 8, dans lequel la 
description hierarchique du processus d'ingenierie 
limite I'accessibilitS et la visibility des donnees de- 
crivant des produits, genSrSes par I'execution de 
noeuds de flux appartenant a un niveau particulier 
de la hiSrarchie aux utilisateurs du systeme ayant 
des privileges appropries pour ledit niveau particu- 
lier. 

10. Procede suivant I'ne quelconque des revendica- 
tions 1 a 9, dans lequel des moyens de liaison de 
retour sont ajoutes audit premier graphe acyclique 
orients, transformant de la sorte ledit premier gra- 
phe acyclique oriente en un graphe orients gSnSra- 
HsS presentant des cycles, grace a quoi chaque 
liaison de retour, ayant exactement un noeud de 

^?** :ss, ffiLJx*iou1 ! ce et exactement un noeucllSe 1 flux de des- 
tination, reprSsente le fait que les donnees dScri- 
vantdes produits, gSnSrSes par une exScution dudit 
noeud de flux peuvent Sventuellement servir d'en- 
trSe pour I'exScution dudit noeud de flux de desti- 
nation, off rant de la sorte la possibilitS de modifier 
les dernieres donnSes decrivant des produits un 
nombre arbitraire de fois. 
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